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(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial 
proceedings which will directly affect or be directly affected by or have a bearing on the 
Board's decision in the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection 
contained in the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The examiner has no comment on the appellant's statement of the grounds of 
rejection to be reviewed on appeal. Every ground of rejection set forth in the Office 
action from which the appeal is taken (as modified by any advisory actions) is being 
maintained by the examiner except for the grounds of rejection (if any) listed under the 
subheading "WITHDRAWN REJECTIONS." New grounds of rejection (if any) are 
provided under the subheading "NEW GROUNDS OF REJECTION." 

NEW GROUND(S) OF REJECTION 
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Claims 21 -25 are rejected under 35 U.S.C. 1 1 2, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

6,327,628 Anuffetal. 12-2001 

(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 

Claims 21-25 are rejected under 35 U.S.C. 112, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject 
matter which applicant regards as the invention. 

Claims 21-25 invokes 35 U.S.C. 112, sixth paragraph. However, the written 
description of the specification does not provide sufficient disclosure of structure or 
material for performing the claimed functions. For instance, 

Claim 21 recites: 

A system for adapting a Web application to a portal application 
comprising: 
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means for adding one or more Web application components to said portal 
application; 

(Regarding the above "means", the specification in paragraph [0023] mentions, "A 
developer would generally move the components over to a portal platform". Therefore, 
the specification fails to point out sufficient structure or material as the "means" for 
performing the functions claimed, except the developer. However, a person can not be 
considered as sufficient structure or material for performing the claimed function for a 
system claim.) 

means for generating a plurality ofportlets within said portal application, 
wherein each of said plurality includes a view for said one or more Web 
application components; 

(Regarding the above "means", the specification in paragraph [0023] mentions "For 
each of the components moved, the developer would write code for a portlet. The 
portlets provide the display space for the information". Therefore, the specification fails 
to point out sufficient structure or material as the "means" for performing the functions 
claimed, except the developer. However, a person can not be considered as sufficient 
structure or material for performing the claimed function for a system claim.) 

means for defining at least one Web flow relationship representing 
interactions between said one or more Web application components; and 

(Regarding the above "means", the specification in paragraph [0023] mentions "As 
described above with respect to FIGURE 2, the developer would then select and write 
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code to handle the Web flow for interactions within the portlets and then convert the 
particular Web flow elements to at least one event that corresponds to the interactions 
that may occur within the portlets...". Therefore, the specification fails to point out 
sufficient structure or material as the "means" for performing the functions claimed, 
except the developer. However, a person can not be considered as sufficient structure 
or material for performing the claimed function for a system claim.) 

means for converting said at least one Web flow relationship into at least 
one interaction event, defined within said plurality of portlets, wherein said 
at least one interaction event corresponds to said interactions. 

(Regarding the above "means", the specification in paragraph [0023] mentions "As 
described above with respect to FIGURE 2, the developer would then select and write 
code to handle the Web flow for interactions within the portlets and then convert the 
particular Web flow elements to at least one event that corresponds to the interactions 
that may occur within the portlets...". Therefore, the specification fails to point out 
sufficient structure or material as the "means" for performing the functions claimed, 
except the developer. However, a person can not be considered as sufficient structure 
or material for performing the claimed function for a system claim.) 

Claim 22 recites: 

The system of claim 21 further comprising: 



Application/Control Number: 10/765,378 Page 6 

Art Unit: 2179 

means for creating a customization interface for obtaining 
customization information from a user, 

(Regarding the above "means", the specification in paragraph [0024] mentions 
"Depending on the application or content being offered by the portal, the developer may 
select the level of customization or personalization to allow in the portal and implement 
the selected customization through appropriate computer code. In step 400, a 
customization application is coded by the developer to interact with the user to obtain 
customization information " (emphasis added). Therefore, the specification fails to point 
out sufficient structure or material as the "means" for performing the functions claimed, 
except the developer. However, a person can not be considered as sufficient structure 
or material for performing the claimed function for a system claim.) 

Claim 23 recites: 

The system of claim 22 further comprising: 

means for generating a storage utility to store said customization 
information in said portal application. 

(Regarding the above "means", the specification in paragraph [0024] 
mentions "This information may then be stored in step 402 by defining a storage utility in 
the appropriate underlying computer code for storing the information obtained from the 
user in the portal framework". The specification as shown above mentions "defining a 
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storage utility in the appropriate underlying computer code". The question is, what is the 
means for "generating a storage utility"? Is it the developer who is generating the 
underlying computer code, or is it the "appropriate underlying computer code"? 
Therefore, Applicants failed to clearly link or associate the disclosed structure or 
material to the claimed function. Additionally, neither a developer nor mere mentioning 
of "appropriate underlying computer code" without providing some detail/algorithm 
about the code is considered to be sufficient structure or material to satisfy the 
requirements of 35 U.S.C. 112, second paragraph.) 

Claim 24 recites: 

The system of claim 21 further comprising: 

means for modifying business logic of said one or more Web 
application components to return output as a data-descriptive meta 
language document. 

(Regarding the above "means", the specification in paragraph [0025] mentions 
"Additionally or alternatively, a developer may select a certain level or procedure to 
separate the business logic end from the presentation logic end and implement the 
selected separation in the code structure of the portal. In one embodiment illustrated by 
step 403, the business logic is modified to return its output as extensible markup 
language (XML) documents." The question is, what is the means for "modifying the 
business logic"? Is it the developer who "implement(s) the selected separation in the 
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code structure of the portal", or is it the "code structure"? Therefore, Applicants failed to 
clearly link or associate the disclosed structure or material to the claimed function. 
Additionally, neither a developer nor mere mentioning of mere "code structure" without 
providing some detail/algorithm about the code, is considered to be sufficient structure 
or material to satisfy the requirements of 35 U.S.C. 112, second paragraph.) 

Claim 25 recites: 

The system of claim 21 further comprising: 

means for creating a service interface to search a plurality of Web 

services; and 

(Regarding the above "means", the specification in paragraph [0026] mentions 
"Additionally or alternatively to the modification of the existing business logic, client 
components may be created using appropriate code designed by the developer in step 
404 for locating Web services to provide the business logic to the portal." The question 
is, what is the means for "creating a service interface"? Is it the developer who is 
generating the appropriate code, or is it the "appropriate code"? Therefore, Applicants 
failed to clearly link or associate the disclosed structure or material to the claimed 
function. Additionally, neither a developer nor mere mentioning of "appropriate code" 
without providing some detail/algorithm about the code, is considered to be sufficient 
structure or material to satisfy the requirements of 35 U.S.C. 112, second paragraph.) 
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means for coding said service interface to select one or more of said 
plurality of Web services to provide business logic to said portal 
application. 

(Regarding the above "means for coding", it is reasonable to believe that only the 
developer is the "means for coding". In other words, software does not "code", but 
a developer is the one who codes. However, a person can not be considered as 
sufficient structure or material for performing the claimed function for a system claim.) 

Claims 1-25 are rejected under 35 U.S.C. 102(b) as being anticipated by 
Anuff et al. (US 6,327,628) hereinafter Anuff. 

For claims 1 -5, 7-1 0, 1 2-1 5, 1 7-20 and 22-25, Anuff teaches a computer 

implemented system and corresponding method comprising: 

determining a construction design for an adapted portal application wherein said 

determining a construction design includes one or more of: 

determining a visual theme of said adapted portal application (determining 
a visual theme means determining the look and feel of the portal 
application, column 2 lines 13-16, also subsection 8-8.6); and 
determining a format of content for said adapted portal application 
(content is formatted in a predetermined layout, Abstract and column 2 
lines 1-3, also subsection "3.4 page layout"); 
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determining a model for separation or presentation logic and application logic of 
an existing Web application to be adapted into said portal application (Anuff teaches 
that the views are the means by which the portal server isolates the presentation logic 
from the application logic, subsection 3.3.2); 

determining a navigation construction for said adapted portal application wherein 
said determining a navigation construction includes: 

retrieving selected information based on an event defined by uniform 
resource locator (URL) interaction in said Web application (Fig. 2 shows 
various URLs that are usable to retrieve selected information based on an 
event such as clicking a URL, also link 22 as mentioned in column 3 lines 
52-54); 

selecting a level of customization to apply to said adapted portal application 
wherein said selecting a level of customization comprises one or more of: 

presenting an interactive window to obtain customization information from 
a user (buttons or links 24 in Fig. 2 are used to launch an interactive 
window that allow the user to personalize the portal, column 3 lines 52- 
57), wherein said obtained customization information is stored in a portal 
framework (LDAP directory or SQL database shown in Fig. 3, column 9 
lines 30-34, also column 13 lines 25-30); and 
retrieving existing login information related to said user for inclusion in 
content of said adapted portal application (column 9 lines 30-34, also 
column 13 lines 25-30); 
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selecting an isolation model for isolating business logic from said adapted portal 
application wherein said selecting an isolation model comprises one or more of: 
modifying said business model to return output as at least one data- 
descriptive meta language document (column 10 lines 52-62); and 
creating a component to connect said adapted portal application to one or 
more Web services for providing said business logic to said adapted portal 
application (the server part of the portal server shown in Fig. 3, column 4 
lines 16-33); and 

employing the determined construction design, the determined model, the 
determined navigation construction, the selected level of customization, and the 
selected isolation model for adapting said existing Web application into said 
portal application in a manner that maintains said existing Web application's 
functionality within said portal application (implied in the reference since such 
employment is necessary in order to realize the disclosed portal infrastructure 
that is intended to maintain the existing Web application's functionality within the 
modular portal infrastructure but in a streamlined and cost effective manner 
(d:40:62). 

For claims 6, 1 1 and 21 , Anuff teaches adapting a web application to a portal 
application comprising: 
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adding at least one component of said Web application to a portal platform (Fig. 
2 shows various components of a web application such as Search, Company Directory, 
News and Discussion Boards that are added to a portal platform); 

creating a plurality of portlets within said portal platform, wherein each of said 
plurality includes pages representing a view for said at least one component of said 
Web application (each module displayed on the portal front page as shown in Fig. 2 is a 
portlet that contains pages representing a view for a particular network resource); 

defining at least one Web flow relationship representing interactions between 
said at least one component of said Web application (defining at least one Web flow 
relationship is inherent in the reference since there has to be a defined Web flow 
relationship in order to show the appropriate page based on the user interaction at the 
portal, Fig. 2); and 

converting said at least one Web flow relationship into at least one event, defined 
within said plurality of portlets, wherein said at least one event corresponds to said 
interactions (Anuff teaches implementing the defined Web flow relationship by 
converting it into user selection events such as selecting a link or button in order to 
display appropriate page based on the selection, Fig. 2). 

For claim 16, Anuff further teaches displaying a second user interface to a user 
for updating the personal login information ("Edit Account" link in Fig. 2). 
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(10) Response to Argument 

Beginning on page 1 1 of Appellant's brief (hereinafter Brief), Appellant argues 
specific issues, which are accordingly addressed below. Appellant has elected to group 
the following claims together and only present arguments for claims 1 , 3, 6, 1 1 , 1 9, 21 , 
and 24. Therefore, the Examiner will present arguments based on the elected 
groupings. 

Independent Claim 1 and Dependent Claims 2 and 4-5 

Regarding Claim 1 , Appellant mentions, "Anuff fails to teach all elements of claim 1." 
However, in particular, Appellant argues, "While Anuff proposes a modular portal 
infrastructure or framework, Anuff fails to address any technique for adapting an existing Web 
application into the proposed portal infrastructure." 

In response to the above arguments, the Final Office Action explained the 
rationale for the rejection based on an interpretation of the recited "existing Web 
application". The explanation for the rejection provided in the Final Office Action is 
provided below for the convenience of the reader. 

"For claim 1, Applicant argues, 'while Anuff proposes a modular portal infrastructure or 
framework, Anuff fails to address any technique for adapting an existing Web application into 
the proposed portal infrastructure' (Applicant's Remarks: pl5: 21-23). The Examiner disagrees. 
It appears that the Applicant relies on the fact that Anuff does not disclose adapting an instance 
of an implementation of a Web application into a portal infrastructure. The Examiner realizes 
that Anuff does not explicitly teach a technique that takes coded components, in other words an 
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instance of an implementation, of a Web application and modify or incorporate those coded 
components to form corresponding modules to be used in its portal framework, although such 
modification would have been obvious based on his teachings. But such limitation is not required 
by the claim as it is drafted at present. A "Web application" as recited in the claim, can 
reasonably be interpreted, in the broadest reasonable interpretation, to mean a concept of a Web 
application. For example, just the concept of searching the web with a keyword for retrieving 
information relevant to the keyword can be broadly referred to as a Web application, even 
though this concept can be implemented using various different techniques as various different 
instances of implementation of the Web application. Therefore, "an existing Web application" as 
recited in the claim can reasonably be interpreted to mean "a known concept of a Web 
application" and not necessarily be interpreted to be an existing instance of a particular 
implementation of a Web application. Interpreted as such, claim 1 only requires a method for 
adapting a known concept of a Web application into a portal infrastructure using the steps 
recited. Note that the claim does not need that an existing instance of an implementation be 
present and modified or incorporated or adapted into the portal infrastructure. In other words, the 
portal infrastructure can be implemented from scratch if needed. Therefore, 'an existing Web 
application to be adapted into said portal application' only requires use of a known concept of a 
Web application and to make it suitable to or fit for a specific use or situation (American 
Heritage Dictionary defines the word "adapt" as "To make suitable to or fit for a specific use or 
situation") by implementing the concept as a portal framework. Such a portal framework is thus 
an "adapted portal application ' as recited in claim 1 . Anuff teaches a modular portal 
infrastructure that uses the existing concepts of browser applications (e.g., Web applications such 
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as web search, company directory search, News etc. as shown in Fig. 2) and adapts those 
application concepts to meet the desire of today's corporate users 'to have quick access to 
various resources and data provided by the employer, while at the same time being able to view 
information provided over the internet, such as news headlines, financial data, and vendor data' 
(c3:36-39) at once from a single site using a portal infrastructure. Anuff further realizes that the 
use of a portal infrastructure to adapt existing Web application concepts into a one-site gateway 
to the Web was not a new concept or technique. He teaches that by the time of his invention 
'portals have become popular mechanisms that enable users to access information from multiple 
different network sites at once' (c3:37-39). Therefore, even the concept of a portal infrastructure 
itself can be thought of as "an existing Web application" at the time of the invention. Therefore, 
it can be said that Anuff further teaches a technique for adapting an existing portal Web 
application into a modular portal infrastructure to make it suitable to or fit for the current 
organizational need for streamlining the processes involved in offering a feature-rich portal while 
minimizing the complexity and cost of developing, deploying, administering and continually 
enhancing portals (cl :40-62). Therefore, Anuff clearly anticipates the claim as pointed out in this 
Office Action above." See Final Office Action, pages 7-8. 

In reply to the above argument from the Examiner, Appellant argues in the 
Brief, "Examiner's interpretation of an 'existing Web application ' as a known concept of a Web 
application (which appears to refer to a known functionality that is performed via the Web, such 
as the concept of performing keyword searching over the Web) is unreasonably broad. The claim 
language should be interpreted consistent with the specification of the application. That is, the 
claims are to be given their broadest reasonable interpretation in light of the specification, see 
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M.P.E.P. §2111. "Claims are not to be read in a vacuum, and limitations therein are to be 
interpreted in light of the specification in giving them their 'broadest reasonable interpretation' ." 
M.P.E.P. § 2111.0 1 (II), quoting In reMarosi, 710 F.2d 799, 218 USPQ 289 (Fed. Cir. 1983). 
Indeed, if read in a vacuum, the word "Web" could be interpreted as a spider web, rather than the 
well-known computer network referred to as the "Web". Likewise, when properly interpreted in 
light of its usage in the specification of the present application, "an existing Web application" is 
not reasonably interpreted as referring to any known function (or concept) that can be performed 
via the Web." Applicant further cited portions of the instant specification asserting that the 
limitation "existing Web application" when afforded a reasonable interpretation 
consistent with its use in the specification of the present application is an instance of an 
implementation of a Web application, rather than a concept of a Web application and 
asserts that Anuff fails to teach this limitation of claim 1 as conceded by the Examiner in 
the Final Office Action. See Brief, page 14. 

In response to applicant's argument the Examiner notes that MPEP 21 1 1 .01 (II) 
states that the claims are interpreted by the Office (PTO) based on their plain meaning 
unless such a meaning is inconsistent with the specification. Further, MPEP 21 1 1 .01 
(III) states that the plain meaning refers to the ordinary and customary meaning given to 
the term by those of ordinary skill in the art in question at the time of the invention. 
Based on the above guidance, the Examiner considers the ordinary and customary 
meaning given to the term "existing Web application" by those of ordinary skill in the art 
in question at the time of the invention would have been "a known concept of a Web 
application" when considered broadly and such interpretation is not inconsistent with the 
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disclosure provided in the instant specification, and thus not unreasonable. Therefore 
the Examiner believes the rejection to be proper. 

However, upon further consideration of the reference in question for the 
preparation of this Answer, the Examiner believes that Anuff in fact teaches adapting an 
existing Web application into a proposed portal infrastructure even if the terminology "an 
existing Web application" is interpreted to mean not just a known Web application (i.e., 
in the form of a concept or knowledge) but an actual instance of a particular 
implementation of a Web application (i.e., a Web application constructed from a number 
of Web components appropriately coded by the developer that provide some 
information or application logic to the user). This is because Anuff teaches that each 
module within the portal represents a network resource (i.e., a Web application) that can 
be accessed by a user through the portal (see Abstract). He further mentions, "As will be 
apparent from the discussion that follows, these resources can be applications, databases, 
services informational content, e-commerce offerings, and the like, that are available from one or 
more of the servers 12a-12n. Some of these resources may be provided by the employer (or other 
provider of the portal), whereas others may come from independent third parties ." Emphasis 
added, see c3:61 -c4:1 . Elsewhere he again mentions, "One of the significant advantages of 
the portal framework of the present invention is the fact that the resources that are made 
available to the user via the modules can come from a variety of third-party sources . Emphasis 
added, see c1 0:52-55. Since some of the modules on the portal platform make available 
to the user resources provided by third parties, it follows that these third party resources 
represent existing Web applications, since at least these third party resources are not 
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built from scratch by the portal provider but represents resources that are already 
provided by third parties. Therefore, by providing access to these third party Web 
application resources via designing and implementing the modular portal, Anuff teaches 
a technique for adapting an existing Web application into the proposed portal 
infrastructure. The notion that Anuff teaches a technique for adapting an existing Web 
application to the portal platform is further supported by the teaching that the portal is 
said to be an object-oriented system built on an object model, illustrated in Figs. 4, 6 
and 7, using objects built on top of existing objects. Regarding the object model built 
using object oriented paradigm, Anuff mentions, "Software objects are also extensible: other 
objects can be built on top of existing objects , allowing the new object to extend the concept of 
the old object without having to rewrite the functionality ". Emphasis added, see c4:54-57. 

That is, Anuff at least implicitly teaches that the modular portal is built using new module 
objects which extend the concept of old module objects without having to rewrite the 
functionality. Additionally, Anuff elsewhere teaches utilizing technology for allowing 
configuration-data driven resolution of service implementations within the portal server, 
and mentions, "This allows the portal provider to use existing implementations or define their 
own, and substitute their chosen implementation into the system without rewriting source code 
that uses the implementation ." Emphasis added, see c5:49-67. It is because Anuff 
incorporates components of existing Web applications into his portal platform for 
adapting an existing Web application into the proposed portal infrastructure, that "an 
entire working portal can be up and running very quickly: in hours or days, rather than weeks or 
months that were required prior to the invention. Organizations can, at their own pace, change all 



Application/Control Number: 10/765,378 Page 19 

Art Unit: 2179 

aspects of the look-and-feel of the portal, integrate their own content, and use the portal server's 
development tools to extend out-of-the-box functionality... thereby promoting integration with 
existing systems and reducing required learning time." See d 7:27-37. Referring to Fig. 2 
again, none of the modules 26 such as "Bookmarks", "Search", "Company Directory", 
"News", and "Discussion Boards" represent any novel Web service functionality but are 
known functionalities in the art at the time of the invention. It would be unreasonable to 
believe that a person of ordinary skill in the art would rewrite the code for these modules 
from scratch. In the contrary, a skilled artisan would readily realize that one is more 
likely to re-use existing codes for developing at least some portions of these modules as 
part of the modular portal platform. Therefore, the Examiner believes that Anuff teaches 
a technique for adapting and existing Web application into the proposed portal 
infrastructure whether the terminology "an existing Web application" is interpreted as 
mere concept or not. 

For claims 2 and 4-5, the Appellant has not provided any additional argument 
besides what has been already discussed above with respect to claim 1 . Therefore, the 
same argument applies for these claims. 

Dependent Claim 3 

Dependent claim 3 depends from claim 1. Therefore, the same argument as 
discussed with respect to claim 1 above also applies to this claim. Appellant further 
argues, "Anuff further fails to teach creating a new window for information retrieved in 
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response to a call to a URL from a Web application". See page 1 5 in the Brief. The 
Examiner disagrees. Referring to Fig. 2, Anuff shows portlets, i.e., modules 26, with 
titles "Bookmarks", "Search", "Company Directory", "News" and "Discussion Boards". 
Each of these modules either alone or in combination has been relied upon as "said 
Web application" recited in the claim (see the discussion with respect to claim 1 above). 
The illustration of Fig. 2 shows a "Portal Front Page" 18 (see c3:44-45). This "Portal 
Front Page" is also illustrated in the object model of Fig. 4. As shown, a module window 
corresponds to a "View" object in the object model of Fig. 4. Now referring to section 
3.3.2 Views, Anuff teaches, "Examples of views are the front page of a portal, where a module 
is displayed within a box or other graphical region (as shown in Fig. 2);" (see c6:51 -54). He 
further mentions, "A new view object is created for each HTTP request." (see c6:57-58). 
From the above description, it is apparent that a "View" object corresponds to a 
"window" containing the module 26 of the Portal Front Page as illustrated in Fig. 2. Also, 
it is implicit in the reference that the news headlines displayed in the News module in 
Fig. 2 are URLs. Now based on the teaching that by interacting with any one of these 
modules, the user can access the information or services provided by that module, and 
by clicking on a headline in the "News" module, the user can be presented with the full 
text of the news story to which that headline pertains (see c4:1-5), it is apparent that 
Anuff teaches retrieving information in response to a call to a URL from a Web 
application. Furthermore, since it is well known that a URL call generates an HTTP 
request (also shown as HTTP Connection in Fig. 12), and the explicit teaching "a new 
view (i.e., a window) object is created for each HTTP request" (see c6:57-58), it follows 
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that Anuff teaches "creating a new window for information retrieved in response to a call to a 
URL from a Web application". 



Independent Claim 6 and Dependent Claims 7-10 

Regarding claim 6, Appellant mentions, "Anuff fails to teach all elements of claim 6". 
In particular, Appellant argues, "While Anuff proposes a modular portal infrastructure or 
framework, Anuff fails to address any technique for adapting an existing Web application into 
the proposed portal infrastructure. Thus, Anuff fails to disclose a method for 'adapting a Web 
application to a portal application' in the manner recited by claim 6." This appears to be the 
same argument that Appellant has argued for claim 1 . Therefore, the Examiner 
disagrees for the same reasoning as explained above with respect to claim 1 . For the 
sake of brevity, the same argument discussed with respect to claim 1 is not repeated 
here. However, the Examiner would like to point out that claim 6 does not even recite 
the limitation "existing Web application" which was recited in claim 1, but only recites "a 
Web application". Appellant argues, "Indeed , claim 6 expressly recites that the Web 
application has at least one component, and a Web flow relationship is defined representing 
interactions between said at least one component of said Web application... Accordingly, 
interpretation such an existing Web application as a known concept (or function) of the web is 
particularly unreasonably broad with regard to claim 6, which expressly recites that the Web 
application comprises at least one component." See page 17 in the Brief. The Examiner 
disagrees. The limitation "at least one component of said Web application" does not 
necessarily require that the component is a coded component. Therefore, the limitation 
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"adding at least one component of said Web application to a portal platform" can reasonably 
be interpreted to require that the functionality of at least one component of a known 
Web application is provided via a portal platform, even if the Web application is not 
implemented with components appropriately coded by developers, but exists merely in 
conceptual form as prior art knowledge of a skilled artisan. Anuff clearly teaches this. As 
already mentioned above in the response to the argument with respect to claim 1 , Anuff 
realizes that the use of a portal infrastructure to consolidate existing Web applications 
into a one-site gateway to the Web was not a new concept or technique. He teaches 
that by the time of his invention 'portals have become popular mechanisms that enable 
users to access information from multiple different network sites at once' (c3:37-39). 
Therefore, even the concept of a portal infrastructure itself can be thought of as "a Web 
application" existing at the time of the invention. Anuff in fact teaches an improvement 
over the existing portal architecture. Therefore, it can be said that Anuff further teaches 
a technique for adapting an existing portal Web application into a modular portal 
infrastructure to make it suitable to or fit for the current organizational need for 
streamlining the processes involved in offering a feature-rich portal while minimizing the 
complexity and cost of developing, deploying, administering and continually enhancing 
portals (c1:40-62). In other words, referring to the Portal Front Page 18 illustrated in Fig. 
2, one skilled in the art will readily realize that the resources such as "Bookmarks", 
"Search", "Company Directory", "News", and "Discussion Boards" can very well be 
based on components from an existing portal application (i.e., at least one component of 
said Web application), wherein the portal application is not modularized according to the 
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technique espoused by Anuff. The existing portal application and corresponding 
components can exist physically as appropriately coded by developers or can exist in 
the form of mere conception or prior art knowledge of a skilled artisan. However, Anuff 
teaches a portal that incorporates these components as independent modules so that 
they can be readily and independently updated by the entities who provide them, 
without affecting other features of the portal (see c2:9-12). Such incorporation, no 
matter how it is implemented, amounts to " adding at least one component of said Web 
application to a portal platform" as claimed. 

However, upon further consideration of the reference in question for the 
preparation of this Answer, the Examiner believes that Anuff in fact at least implicitly 
teaches "adding at least one component of said Web application to a portal platform" even if 
the terminology "Web application" is interpreted to mean not just a known Web 
application (i.e., in the form of a concept or knowledge) but an actual instance of a 
particular implementation of a Web application (i.e., a Web application constructed from 
a number of Web components appropriately coded by the developer that provide some 
information or application logic to the user). This is because Anuff teaches that each 
module within the portal represents a network resource that can be accessed by a user 
through the portal (see Abstract). He further mentions, "As will be apparent from the 
discussion that follows, these resources can be applications, databases, services informational 
content, e-commerce offerings, and the like, that are available from one or more of the servers 
12a-12n. Some of these resources may be provided by the employer (or other provider of the 
portal), whereas others may come from independent third parties ." Emphasis added, see 
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c3:61 -c4:1 . Elsewhere he again mentions, "One of the significant advantages of the portal 
framework of the present invention is the fact that the resources that are made available to the 
user via the modules can come from a variety of third-party sources . Emphasis added, see 
d 0:52-55. Since some of the modules on the portal platform make available to the user 
resources provided by third parties, it follows that these third party resources represent 
existing Web applications, since at least these third party resources are not built from 
scratch by the portal provider but represents resources that are already provided by 
third parties. Therefore, by providing access to these third party Web application 
resources, which can very well exist as components of prior art portal application, via 
designing and implementing the modular portal, Anuff teaches a technique for adapting 
an existing Web application into the proposed portal infrastructure. The notion that Anuff 
teaches adding at least one component of an existing Web application to the portal 
platform is further supported by the teaching that the portal is said to be an object- 
oriented system built on an object model, illustrated in Figs. 4, 6 and 7, using objects 
built on top of existing objects. Regarding the object model built using object oriented 
paradigm, Anuff mentions, "Software objects are also extensible: other objects can be built on 
top of existing objects , allowing the new object to extend the concept of the old object without 
having to rewrite the functionality ". Emphasis added, see c4:54-57. That is, Anuff at least 
implicitly teaches that the modular portal is built using new module objects which extend 
the concept of old module objects without having to rewrite the functionality. 
Additionally, Anuff elsewhere teaches utilizing technology for allowing configuration-data 
driven resolution of service implementations within the portal server, and mentions, 
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"This allows the portal provider to use existing implementations or define their own, and 
substitute their chosen implementation into the system without rewriting source code that uses 
the implementation ." Emphasis added, see c5:49-67. Therefore, Anuff clearly teaches 
reuse of existing components of a Web application in implementing his modular portal 
infrastructure. It is because Anuff incorporates components of existing Web applications 
into his portal platform for adapting an existing Web application into the proposed portal 
infrastructure, that "an entire working portal can be up and running very quickly: in hours or 
days, rather than weeks or months that were required prior to the invention. Organizations can, at 
their own pace, change all aspects of the look-and-fccl of the portal, integrate their own content, 
and use the portal server's development tools to extend out-of-the-box functionality... thereby 
promoting integration with existing systems and reducing required learning time." See d 7:27- 
37. Referring to Fig. 2 again, none of the modules 26 such as "Bookmarks", "Search", 
"Company Directory", "News", and "Discussion Boards" represent any novel 
functionality but are known functionalities in the art at the time of the invention. It would 
be unreasonable to believe that a person of ordinary skill in the art would rewrite the 
code for these modules from scratch. In the contrary, a skilled artisan would readily 
realize that one is more likely to re-use existing codes for developing at least some 
portions of these modules as part of the modular portal platform. Thus the Examiner 
concludes that Anuff teaches a technique for adapting a Web application to a portal 
application by adding at least one component of said Web application to a portal 
platform. 
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Appellant further argues that Anuff fails to teach "defining at least one Web flow 
relationship representing interactions between said at least one component of said Web 
application; and converting said at least one Web flow relationship into at least one event, 
defined within said plurality of portlets, wherein said at least one event corresponds to said 
interactions." See page 16 in the Brief. Regarding this limitation of claim 6, the Final 
Office Action explained, "defining at least one Web flow relationship is inherent in the 
reference since there has to be a defined Web flow relationship in order to show the appropriate 
page based on the user interaction at the portal. Anuff teaches implementing the defined Web 
flow relationship by converting it into user selection events such as selecting a link or button in 
order to display appropriate page based on the selection. See pages 5-6 of the Final Office 
Action. Appellant argues, "However, this appears to focus on the proposed functionality of a 
given module that is implemented within Anuff s portal framework, rather than a process for 
adapting an existing Web application into the portal (e.g., into the given module). For instance, 
while the operation of a given module within Anuff s portal may support a certain flow of 
interaction with a user by enabling the user to click on a hyperlink, etc., Anuff fails to disclose 
defining a Web flow relationship for a Web application and converting such relationship into an 
event defined in a portlet of a portal in order to adapt a Web application into such portal (e.g., in 
order to adapt a Web application into a module). Indeed, the module of Anuff may be created 
from scratch, rather than attempting to adapt an existing Web application into such modules, as 
Anuff provides no disclosure of any such adapting of an existing Web application into its portal 
framework." See page 17 in the Brief. In response the Examiner contends that since the 
modules within Anuffs portal infrastructure supports certain flow of interaction with a 
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user by enabling a user to click on a hyperlink, this implies that the implementation of 
such flow of interaction necessarily requires that the Web flow relationship representing 
the interaction is defined first at the design or planning stage of development of such a 
portal platform. For further clarification, Anuff teaches the limitation 11 defining at least one 
Web flow relationship representing interactions between said at least one component of said 
Web application" by defining ways or a model of interactions between the user and a 
component at design stage of development, i.e., defining how a user is to interact with a 
component in order to access its service, and teaches the limitation "converting said at 
least one Web flow relationship into at least one event, defined within said plurality of portlets, 
wherein said at least one event corresponds to said interactions" by implementing the defined 
model of interaction into user selection events such as selecting a link or button in order 
to display appropriate page based on the selection. Such teaching can be found 
illustrated as Object Models in Fig. 4, 6 and 7 for designing the portal infrastructure and 
additionally or in the alternative deemed inherent in the reference. 

For claims 7-10, Appellant has not provided any additional argument besides 
what has been already discussed above with respect to claim 6. Therefore, the same 
argument applies for these claims. 

Independent Claim 11 and Dependent Claims 12-18 and 20 

Regarding claim 1 1 , Appellant mentions, "Anuff fails to teach all elements of claim 
11". In particular, Appellant argues, "While Anuff proposes a modular portal infrastructure or 
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framework, Anuff fails to address any technique for converting a Web application into the 
proposed portal infrastructure. Thus, Anuff fails to disclose a method for 'converting a Web 
application to a portal application' in the manner recited by claim 11." This appears to be the 
same argument that Appellant has argued for claim 1 . The terminology "converting" used 
in the claim is considered synonymous to the terminology "adapting" used in claim 1 in 
the context of the invention. Therefore, the Examiner disagrees for the same reasoning 
as explained above with respect to claim 1 . For the sake of brevity, the same argument 
discussed with respect to claim 1 is not repeated here. However, the Examiner would 
like to point out that claim 1 1 does not even recite the limitation "existing Web 
application" which was recited in claim 1, but only recites "a Web application". Appellant 
argues, "Further, the method of claim 1 1 for so converting a Web application into a portal 
application recites, in part, 'moving Web components from said Web application into a portal 
framework corresponding to said portal application'. Anuff fails to disclose at least this step of 
the method... While Anuff discloses modules, Anuff does not disclose that adapting a web 
application to such a module includes moving Web components from said Web application into a 
portal framework (e.g., module) as recited by claim 11." See page 1 8 in the Brief. The 
Examiner disagrees. The limitation "moving Web components from said Web application into 
a portal framework corresponding to said portal application " does not necessarily require 
that the components are coded components and such coded components are physically 
ported or copied to a portal platform. The limitation "moving Web components from said 
Web application into a portal framework corresponding to said portal application " can 
reasonably be interpreted to require providing functionalities that belongs to, or 
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corresponds to a known Web application from within a portal platform, even if the Web 
application is not implemented with components appropriately coded by developers, but 
exists merely in conceptual form as prior art knowledge of a skilled artisan. Anuff clearly 
teaches this. As already mentioned above in the response to the argument with respect 
to claim 1 , Anuff realizes that the use of a portal infrastructure to consolidate existing 
Web applications into a one-site gateway to the Web was not a new concept or 
technique. He teaches that by the time of his invention 'portals have become popular 
mechanisms that enable users to access information from multiple different network 
sites at once' (c3:37-39). Therefore, even the concept of a portal infrastructure itself can 
be thought of as "a Web application" existing at the time of the invention. Anuff in fact 
teaches an improvement over the existing portal architecture. Therefore, it can be said 
that Anuff further teaches a technique for adapting an existing portal Web application 
into a modular portal infrastructure to make it suitable to or fit for the current 
organizational need for streamlining the processes involved in offering a feature-rich 
portal while minimizing the complexity and cost of developing, deploying, administering 
and continually enhancing portals (d :40-62). In other words, referring to the Portal 
Front Page 18 illustrated in Fig. 2, one skilled in the art will readily realize that the 
resources such as "Bookmarks", "Search", "Company Directory", "News", and 
"Discussion Boards" can be components from an existing portal application (i.e., Web 
components from said Web application), wherein the portal application is not modularized 
according to the technique espoused by Anuff. The existing portal application and 
corresponding components can exist physically as appropriately coded by developers or 



Application/Control Number: 10/765,378 Page 30 

Art Unit: 2179 

can exist in the form of mere conception or prior art knowledge of a skilled artisan. 
However, Anuff teaches a portal that incorporates these components as independent 
modules so that they can be readily and independently updated by the entities who 
provide them, without affecting other features of the portal (see c2:9-12). Such 
incorporation, no matter how it is implemented, amounts to "moving Web components from 
said Web application into a portal framework" as claimed. 

However, upon further consideration of the reference in question for the 
preparation of this Answer, the Examiner believes that Anuff in fact at least implicitly 
teaches "moving Web components from said Web application into a portal framework 
corresponding to said portal application " even if the terminology "Web application" is 
interpreted to mean not just a known Web application (i.e., in the form of a concept or 
knowledge) but an actual instance of a particular implementation of a Web application 
(i.e., a Web application constructed from a number of Web components appropriately 
coded by the developer that provide some information or application logic to the user), 
and "moving the Web components" is interpreted to necessarily require that the 
components are coded components and such coded components are physically ported 
or copied to a portal platform. This is because Anuff teaches that each module within 
the portal represents a network resource that can be accessed by a user through the 
portal (see Abstract). He further mentions, "As will be apparent from the discussion that 
follows, these resources can be applications, databases, services informational content, e- 
commerce offerings, and the like, that are available from one or more of the servers 12a-12n. 
Some of these resources may be provided by the employer (or other provider of the portal), 
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whereas others may come from independent third parties ." Emphasis added, see c3:61-c4:1. 
Elsewhere he again mentions, "One of the significant advantages of the portal framework of 
the present invention is the fact that the resources that are made available to the user via the 
modules can come from a variety of third-party sources . Emphasis added, see d 0:52-55. 
Since some of the modules on the portal platform make available to the user resources 
provided by third parties, it follows that these third party resources represent existing 
Web applications, since at least these third party resources are not built from scratch by 
the portal provider but represents resources that are already provided by third parties. 
Therefore, by providing access to these third party Web application resources, which 
can very well exist as components of prior art portal application, via designing and 
implementing the modular portal, Anuff teaches a technique for adapting an existing 
Web application into the proposed portal infrastructure. The notion that Anuff teaches 
moving Web components of an existing Web application to the portal platform is further 
supported by the teaching that the portal is said to be an object-oriented system built on 
an object model, illustrated in Figs. 4, 6 and 7, using objects built on top of existing 
objects. Regarding the object model built using object oriented paradigm, Anuff 
mentions, "Software objects are also extensible: other objects can be built on top of existing 
objects , allowing the new object to extend the concept of the old object without having to rewrite 
the functionality ". Emphasis added, see c4:54-57. That is, Anuff at least implicitly 
teaches that the modular portal is built using new module objects which extend the 
concept of old module objects without having to rewrite the functionality. Additionally, 
Anuff elsewhere teaches utilizing technology for allowing configuration-data driven 
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resolution of service implementations within the portal server, and mentions, "This allows 
the portal provider to use existing implementations or define their own, and substitute their 
chosen implementation into the system without rewriting source code that uses the 
implementation ." Emphasis added, see c5:49-67. Therefore, Anuff clearly teaches reuse 
of existing components of a Web application in implementing his modular portal 
infrastructure. It is because Anuff incorporates components of existing Web applications 
into his portal platform for adapting an existing Web application into the proposed portal 
infrastructure, that "an entire working portal can be up and running very quickly: in hours or 
days, rather than weeks or months that were required prior to the invention. Organizations can, at 
their own pace, change all aspects of the look-and-feel of the portal, integrate their own content, 
and use the portal server's development tools to extend out-of-the-box functionality... thereby 
promoting integration with existing systems and reducing required learning time." See d 7:27- 
37. Referring to Fig. 2 again, none of the modules 26 such as "Bookmarks", "Search", 
"Company Directory", "News", and "Discussion Boards" represent any novel web 
service functionality but are known functionalities in the art at the time of the invention. It 
would be unreasonable to believe that a person of ordinary skill in the art would rewrite 
the code for these modules from scratch. In the contrary, a skilled artisan would readily 
realize that one is more likely to re-use existing codes for developing at least some 
portions of these modules as part of the modular portal platform. Thus the Examiner 
concludes that Anuff teaches a technique for converting a Web application into a portal 
application by moving Web components from said Web application into a portal 
framework corresponding to said portal application. 
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For claims 12-18 and 20, Appellant has not provided any additional argument 
besides what has been already discussed above with respect to claim 1 1 . Therefore, 
the same argument applies for these claims. 

Dependent Claim 19 

Dependent claim 1 9 depends from claim 1 1 . Therefore, the same argument as 
discussed with respect to claim 1 1 above also applies to this claim. Appellant further 
argues, "Anuff further fails to teach creating a new window for information retrieved in 
response to a call to a URL from a Web application". See page 1 9 in the Brief. The 
Examiner disagrees. Referring to Fig. 2, Anuff shows portlets, i.e., modules 26, with 
titles "Bookmarks", "Search", "Company Directory", "News" and "Discussion Boards". 
Each of these modules either alone or in combination has been relied upon as "said 
Web application" recited in the claim (see the discussion with respect to claim 1 1 
above). The illustration of Fig. 2 shows a "Portal Front Page" 18 (see c3:44-45). This 
"Portal Front Page" is also illustrated in the object model of Fig. 4. As shown, a module 
window corresponds to a "View" object in the object model of Fig. 4. Now referring to 
section 3.3.2 Views, Anuff teaches, "Examples of views are the front page of a portal, where 
a module is displayed within a box or other graphical region (as shown in Fig. 2);" (see c6:51 - 
54). He further mentions, "A new view object is created for each HTTP request." (see c6:57- 
58). From the above description, it is apparent that a "View" object corresponds to a 
"window" containing the module 26 of the Portal Front Page as illustrated in Fig. 2. Also, 



Application/Control Number: 10/765,378 Page 34 

Art Unit: 2179 

it is implicit in the reference that the news headlines displayed in the News module in 
Fig. 2 are URLs. Now based on the teaching that by interacting with any one of these 
modules, the user can access the information or services provided by that module, and 
by clicking on a headline in the "News" module, the user can be presented with the full 
text of the news story to which that headline pertains (see c4:1-5), it is apparent that 
Anuff teaches retrieving information in response to a call to a URL from a Web 
application. Furthermore, since it is well known that a URL call generates an HTTP 
request (also shown as HTTP Connection in Fig. 12), and the explicit teaching "a new 
view (i.e., a window) object is created for each HTTP request" (see c6:57-58), it follows 
that Anuff teaches "creating a new window for information retrieved in response to a call to a 
URL from a Web application". 

Independent Claim 21 and Dependent Claims 22-23 and 25 

Regarding Claim 21 , Appellant mentions, "Anuff fails to teach all elements of claim 
1." However, in particular, Appellant argues, "While Anuff proposes a modular portal 
infrastructure or framework, Anuff fails to address any technique for adapting an existing Web 
application into the proposed portal infrastructure. Thus, Anuff fails to disclose a method for 
'converting a Web application to a portal application' in the manner recited by claim 11." This 
appears to be the same argument that Appellant has argued for claim 1 . Therefore, the 
Examiner disagrees for the same reasoning as explained above with respect to claim 1 . 
For the sake of brevity, the same argument discussed with respect to claim 1 is not 
repeated here. Appellant argues that Anuff fails to disclose "means for defining at least 
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one Web flow relationship" and "means for converting said at least one Web flow 
relationship". It has been already discussed with respect to claim 6 above that Anuff 
teaches defining at least one Web flow relationship and converting said at least one 
Web flow relationship (see pages 19-20 above). As for the means, the Brief mentions 
computer-executable software code executing on a computer to be the means for 
performing the above functions. Anuff also uses computer-executable software code 
executing on a computer to perform these functions and therefore anticipates the claim. 

For claims 22-23 and 25, Appellant has not provided any additional argument 
besides what has been already discussed above with respect to claim 21 . Therefore, 
the same argument applies for these claims. 

Dependent Claim 24 

Dependent claim 24 depends from claim 21 . Therefore, the same argument as 
discussed with respect to claim 21 above also applies to this claim. Appellant further 
argues, "Anuff further fails to teach modifying business logic of a Web application component 
to return output as a data-descriptive meta-language document". See page 21 in the Brief. The 
Examiner disagrees. Anuff clearly mentions, "One of the significant advantages of the portal 
framework of the present invention is the fact that the resources that are made available to the 
user via the modules can come from a variety of third-party sources. Consequently, however, the 
content for the modules may be largely unstructured, which can be problematic when it is to be 
made available for manipulation and display within the portal. To this end, therefore, a parser 
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technology is employed for retrieving data from external web sites and various other sources, 
translating the data into XML, and returning structured results as objects for use by other entities, 
such as modules. " (Emphasis added, see d 0:52-62). Therefore applying a parser for 
translating the data amounts to modifying business logic of Web application 
components (i.e., third party sources) to return output as data-descriptive meta- 
language document (i.e., XML). Since the means is said to be computer-executable 
software code executing on a computer, and the parser is clearly a computer- 
executable software code executing on a computer, Anuff anticipates the claimed 
limitation. 

(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the 
Related Appeals and Interferences section of this examiner's answer. 

For the above reasons, it is believed that the rejections should be sustained. 

This examiner's answer contains a new ground of rejection set forth in 
section (9) above. Accordingly, appellant must within TWO MONTHS from the 
date of this answer exercise one of the following two options to avoid sua sponte 
dismissal of the appeal as to the claims subject to the new ground of rejection: 

(1) Reopen prosecution. Request that prosecution be reopened before the 
primary examiner by filing a reply under 37 CFR 1.111 with or without amendment, 



Application/Control Number: 10/765,378 Page 37 

Art Unit: 2179 

affidavit or other evidence. Any amendment, affidavit or other evidence must be relevant 
to the new grounds of rejection. A request that complies with 37 CFR 41 .39(b)(1 ) will be 
entered and considered. Any request that prosecution be reopened will be treated as a 
request to withdraw the appeal. 

(2) Maintain appeal. Request that the appeal be maintained by filing a reply brief 
as set forth in 37 CFR 41 .41 . Such a reply brief must address each new ground of 
rejection as set forth in 37 CFR 41 .37(c)(1 )(vii) and should be in compliance with the 
other requirements of 37 CFR 41 .37(c). If a reply brief filed pursuant to 37 CFR 
41 .39(b)(2) is accompanied by any amendment, affidavit or other evidence, it shall be 
treated as a request that prosecution be reopened before the primary examiner under 
37 CFR 41.39(b)(1). 

Extensions of time under 37 CFR 1 .1 36(a) are not applicable to the TWO 
MONTH time period set forth above. See 37 CFR 1 .136(b) for extensions of time to 
reply for patent applications and 37 CFR 1 .550(c) for extensions of time to reply for ex 
parte reexamination proceedings. 

Respectfully submitted, 
/Rashedul Hassan/ 
Examiner, Art Unit 2179 
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A Technology Center Director or designee must personally approve the 
new ground(s) of rejection set forth in section (9) above by signing below: 

/Meng-Ai An/ 

Acting Director TC 2100 

Conferees: 
/Weilun Lo/ 

Supervisory Patent Examiner, Art Unit 2179 



/Ba Huynh/ 

Primary Examiner, Art Unit 2179 



